One manner of performing user authentication involves utilizing credentials. Credentials generally refer to various inputs that may be provided by a user that are specific to that user. Examples of credentials include user identifiers (e.g., login name or email address), passwords, biometric data such as a photograph, fingerprint, voice sample, etc. In many systems, a user provides a credential to an authentication server, which can authenticate the user based on the received credentials.
However, with the proliferation of attacks against users, small and large-scale websites, and networks, the need to properly authenticate a user—i.e., determine that a user actually is who they claim to be—before providing service has become critically important. For example, the proliferation of phishing, fake websites, trojans, viruses, spyware, worms, and keystroke loggers has continued to spread, leaving many authentication systems vulnerable as simple credentials may be stolen.
One approach to dealing with such problems is through providing more complex authentication schemes. An authentication scheme may specify a set of credentials to be collected from users, and the manner in which the authentication is to be performed. For example, a simple authentication scheme involves receiving a user identifier (e.g., username or email address) and an associated password, which can be compared with corresponding values known to an authentication server.
A more involved authentication scheme involves using two-factor authentication (or “2FA”). For example, many banking system websites/applications utilize two-factor authentication during a login process. In such schemes, a user must identify themselves to the system by providing something that only the user is supposed to know (e.g., a password or PIN), and providing something that only the user is supposed to have (e.g., a One-Time Password—or OTP—using a two-factor authentication token).
A one-time password is typically a string of numbers (i.e., numeric) or combination of letters and/or numbers (i.e., alphanumeric) that must be provided before a user is provided access to a service. In some scenarios, the OTP may be configured to only be valid for a short period of time to enhance the security of the OTP, after which a new OTP is required. Two-factor authentication tokens are available in different forms, and may include hardware tokens (e.g., “key fobs” or “dongles”) or the use of a user-associated mobile device (e.g., cellular phone) to receive a OTP over a separate channel, such as using voice, SMS, or USSD.
One or multiple authentication schemes may be employed by an authentication server to protect one application or many different applications. This may be due to different sensitivities of different resources or functionalities provided by the application or applications.
Another more involved authentication scheme is referred to as transaction signing (or digital transaction signing). Transaction signing requires users to digitally “sign” transactions that may be deemed high risk, and is used to verify the authenticity and integrity of an online transaction. As used herein, a transaction need not refer to a monetary transaction, but may refer to any particular interaction between a user and a system—such as a request to execute a function, change profile data, transfer funds, delete a file, etc. Transaction signing may be thought of as another layer on top of traditional two-factor authentication methods.
In transaction signing, a user (or device of the user) is tasked with confirming a transaction using (at least in part) data that is based upon details of the transaction. For example, an implementation of transaction signing may include executing a keyed hash as a function of a user's private or secret key and transaction details specific to the transaction, which results in a unique string which can be used to verify both the authenticity and integrity of an online transaction.
As one example, a user may be asked to enter a dynamic PIN value, which may be generated based upon information specific to a transaction, such as a recipient account number involved in a funds transfer transaction, a filename involved in a delete file transaction, a new ZIP or area code being provided for a profile update transaction, etc.
Using transaction signing techniques, if an attacker attempts to somehow change details of a requested transaction (e.g., change a recipient account number of a money transfer request), the “signature” would be void and the transaction will not be approved.
Although transaction signing can be an effective method to detect interception and modification of your transactions due to attackers (e.g., malware, viruses, “man-in-the-middle” attackers, etc.), transaction signing has not yet been widely deployed. In particular, it is very difficult and cumbersome for an application developer to add transaction signing protections into an application, as numerous technical and operational challenges are introduced.
For example, many application developers do not have the ability to easily provide hardware tokens to users, utilize separate channels for sending OTPs, etc., and thus these developers would need to increase support needed to help users register tokens, as well as upgrade their application and infrastructure to handle the additional logic to challenge and authenticate the response from customers. Further, transaction signing code tends to be very complex and require intimate knowledge of and/or modification to the application (e.g., know when transaction signing is to be used, know what data is to be used for the authentication, etc.).
Accordingly, there is a tremendous need to find simplified mechanisms to allow applications to implement and benefit from transaction signing authentication techniques.